Many services provided through the Internet require that the user first be authenticated before the services can be provided. “Authentication” is the process of attempting to verify the identity of the sender of a communication. The sender being authenticated may be a person using a computer, a computer itself or a computer program. For example, when accessing a bank account, a user may be required to log in by providing a username and password combination before the bank records can be accessed. Traditionally, a single service provider both authenticates the user and provides the service.
This unified authenticator/service provider model has led to a proliferation of disconnected online user identities, and reduces privacy and convenience of users. Privacy is compromised when a user is asked to identify himself to the service provider for even minimal privileges. Each service provider may therefore maintain private information regarding the user that is subject to theft or misuse. Convenience is compromised by having to manage multiple usernames and passwords for various online activities.
To overcome the disadvantages associated with the traditional centralized model, the federated model has been proposed and implemented by various entities, such as the Liberty Alliance Project (LAP) and the OASIS WS-Security and associated Web Services Interoperability Organization (WS-I). Protocols developed by these organizations allow a web service provider to delegate authentication and/or authorization tasks to a trusted identity provider. This improves the convenience and privacy of the user e.g., by providing a single sign-on (SSO) capability, and gives the user more control over personal information.
FIG. 1 shows an exemplary implementation of a web service federation 10. In this example, user 12 accesses web service consumer (WSC) 14. WSC 14 may be an Internet portal providing weather, stock information, banking information to user 12 via an Internet connection 15. Alternatively, WSC 14 may be an application such as a video-on-demand device for accessing streaming multimedia content. Any device or computer requiring interoperation with a web service provider may be regarded as a WSC. Web service provider (WSP) 16 is an entity that provides services and/or goods to the WSC. WSP 16 provides the requested data or performs a requested action on behalf of WSC 14. Identity provider (IDP) 18 authenticates user 12 and/or WSC 14 to WSP 16, depending on the authentication requirements of the WSP.
WSC 14 has several choices when invoking a WSP. It could invoke the WSP on the user's behalf, in which case the WSP will verify the user's credentials. It could also invoke the WSP on the user's behalf but additionally present its own credentials, in which case the WSP will verify both. Alternatively, the WSC can invoke the WSP in its own right. When a WSC invokes a WSP in its own right, the WSC would have already authenticated the user's identity and a pre-existing relationship exists between the WSC and the WSP, e.g., brokered via the trusted authority 19, that allows the WSP to only verify WSC credentials. The trusted authority provides a registry for federation members and the services that they provide along with authentication requirements. The trusted authority therefore brokers trust between the WSC 14 and WSP 16. In LAP federations, the trusted authority is referred to as a discovery service. It should be noted that from a lifecycle perspective, the trusted authority is not always required. For example, the WSP may be preconfigured with the correct and acceptable authentication mechanisms and WSP endpoint(s). Furthermore, in many cases, the identity provider and trusted authority may be co-located, i.e., the trusted authority may be part of the identity provider.
Each Internet connection 15, which places each of the components of the web service federation 10 in communication with each other, may comprise any of various technologies enabling secure communication. For example, Internet connections 15 may each comprise a transmission control protocol (TCP) connection over which messages are passed by hypertext transfer protocol (HTTP) with transport layer security (TLS), thereby providing a secured, encrypted connection over the Internet. TLS is the successor to the secure sockets layer (SSL) specification. It can be seen that for the web service federation to function, WSC 14, WSP 16, IDP 18, and trusted authority 19 must work together in what is known as a “circle of trust” 20. The phrase, “circle of trust” refers to a group of service providers and identity providers that have business relationships based on a federated architecture and operational agreements and with whom users can transact business in a secure and apparently seamless environment.
FIG. 2 shows a swimlane diagram 50 illustrating an exemplary transaction for supplying federated web services from WSP 16 to WSC 14 and user 12. Exemplary web services could include weather, stock, banking, or multimedia data. User 12 initially submits a request 52 to WSC 14. The request may be made over an Internet connection or locally. The WSC application then sends a SOAP message 54 to WSP 16 to invoke the service. A SOAP message is a message sent using the SOAP protocol, a well-known, widely available protocol for exchanging extensible markup language (XML) based messages over a computer network, typically on top of an HTTP layer. If WSP 16 requires authentication of user 12 prior to supplying the particular service requested, it may send a redirect message 56 to WSC 14, to redirect WSC 14 to IDP 18, for authentication.
WSC 14 then contacts IDP 18 and sends an assertion request 58. The request may include any of various identifying information from user 12, such as a username and password or smart card token. If sufficient, IDP 18 responds with an assertion 60, including a security token. One example of such a security token is a Security Assertion markup Language (SAML) security token, which is a signed message that can be authenticated by WSP 16. The type of security token can be selected by WSC 14. If WSC 14 is not aware of the needed type, then WSC 14 can send interact with trusted authority 19 (FIG. 1) to identify the types of security tokens are that are acceptable by WSP 16. WSC 14 then sends a new invoke message 62, this time including the security token, which assures WSP 16 that user 12 is sufficiently authenticated by IDP 18, which issued the token.
It should be noted here that WSP 16 does not require a separate username and password of user 12, and the username and password need not be stored with the WSP 16. Any number of WSPs can work with IDP 18 to obtain such authentication. Furthermore, the assertion requested and delivered by IDP 18 may be limited to specific facts about the user, rather than the user's actual identity. This is sometimes referred to as a blind credential. For example, if the web service is simply providing a weather forecast, the assertion may provide that the user has authorization to view the weather forecast, and further, the user's zip code (or other geographical identifier such as a city name) so that the weather forecast can be tailored to the user's geographical location.
LAP architecture currently includes specifications for over 20 different security token types and WS-I architecture supports four security tokens. Some of the security tokens supported by LAP and WS-I are SAML security tokens. Each token type can provide a different type of security mechanism, from no additional security (relying instead on the underlying SSL/TLS on top of which HTTP and other transfer protocols are provided) to very strong security. A variety of security mechanisms may therefore be implemented using the various SAML security tokens. This provides flexibility according to need. For example, stronger SAML security tokens provide enhanced security for protecting sensitive information, while weaker SAML security tokens require fewer resources. The level of security can therefore be tailored to the sensitivity of the information being provided to or from the WSP, as well as other considerations.
Since LAP, WS-I, and other security standards bodies only provide specifications for the protocol and schema specifications for interoperation between the WSC and the WSP, the standards and specification do not manage internal functionality of each of the members of the federation. Currently, federation protocols are typically hand-programmed into the business logic at both ends of the conversation. This causes difficulties during the lifecycle of the web service provider due to changes in business requirements and security needs. As a result, a large cost is incurred in manually redeploying an application when new or different security mechanisms or new business logics are required to be incorporated therein.